轻量级威胁建模（LTM）助力快速安全开发
业务繁忙的软件公司不断上马新开发项目。但都是安全开发吗？
名为轻量级威胁建模（LTM）的过程涉及安全开发的利益相关者，确保安全内置而非事后补救。那么，LTM是什么？与传统威胁建模又有何区别呢？
轻量级威胁建模方法
LTM是识别、评估和缓解系统或应用程序中潜在安全威胁和漏洞的高效方法，是传统威胁建模的简化版，不像传统方法那样需要对安全风险进行更为全面详细的分析。
采用LTM方法，我们不会如渗透测试那般手动戳刺系统或应用程序来查看其是否受损。相反，我们会寻找应用程序中“理论上的漏洞”，发现潜在的攻击途径和漏洞。
可以考虑询问下列问题：
● 系统中哪些组件会受到攻击？是怎样的攻击？
● 如果有人侵入，最坏情形如何？
● 公司会因此而遭受什么负面影响？又会给我们的客户带来什么负面影响？
执行LTM的时机是？
最好是在新功能发布、安全控制措施有变，或者现有系统架构或基础设施做出什么更改的时候执行LTM。
理想情况下，在设计阶段之后，进入实现阶段之前执行LTM。毕竟，在流入生产环境之前修复漏洞要容易得多。想要在整个公司范围内推广LTM，就得设立清晰一致的流程和标准，包括定义统一的威胁类别、确定共同的威胁与漏洞源，以及制定风险评估和缓解的标准流程。
如何在公司里执行LTM
要在自家公司内部开展LTM，首先要让内部安全团队主导LTM讨论。随着工程团队逐渐熟悉这一过程，他们就能开始操练自己的威胁模型了。
想要在整个公司范围内推广LTM，就得设立清晰一致的流程和标准，包括定义统一的威胁类别、确定共同的威胁与漏洞源，以及制定风险评估和缓解的标准流程。
需规避的常见LTM错误
安全人员很是擅长威胁建模：他们常会预计最坏情况，在设想极端案例的时候也往往极富想象力。但是这些品质也会导致他们掉入LTM陷阱，比如：
● 过于关注异常值。这指的是LTM演练过程中讨论焦点从最现实的威胁偏向了异常值。要解决这个问题，就要确保彻底了解自己的生态。充分利用自家安全信息与事件管理（SIEM）及其他安全监测系统的信息。比如说，如果你的应用程序编程接口（API）端点遭到了1万次攻击，你就知道你的对手盯上什么了。这也是你的LTM所应该关注的。
● 太技术化。发现理论上的漏洞后，技术人员往往直接进入“解决问题模式”，不去讨论漏洞对公司的影响，而是去“解决”问题和探讨技术实现细节。如果LTM演练中出现这种情况，试着把话题拉回来：告诉团队你还没打算讨论实现问题。先把风险和影响理清了再说。
● 假定只用工具就能搞定风险。开发人员总希望自己的工具能发现所有问题。毕竟，威胁模型又不是用来找到特定漏洞的。相反，威胁模型是要在架构层面上考量系统的整体风险。事实上，不安全的设计本来就是OWASP最新十大Web应用安全风险之一。你需要架构层面上的威胁模型，因为架构安全问题是最难以修复的。
● 忽视潜在威胁和漏洞。威胁建模不是一次性的。我们有必要定期重新评估潜在威胁和漏洞，抢在不断变化的攻击方法和恶意攻击者前头。
● 不审查高级实现策略。一旦确定了潜在的威胁和漏洞，就必须采取有效对策来缓解或清除这些威胁和漏洞。可采取的动作包括实现技术控制措施，比如输入验证、访问控制或加密，以及非技术控制措施，比如员工培训或行政政策。
结语
LTM是识别、评估和缓解潜在安全威胁和漏洞的高效方法。该方法对开发人员非常友好，可以通过在软件开发生命周期（SDLC）早期进行威胁建模来推动安全编码。更妙的是，LTM可以由软件开发人员和架构师自己完成，不用依赖实验室进行威胁建模。
通过持续有效地开发和实现LTM，公司能够高效识别和解决最关键的安全风险，同时避开常见陷阱和错误。
参考阅读
同理心是加强威胁建模的关键
安全的生命周期不是开发人员的生命周期
填补安全与开发团队之间鸿沟的四个关键
开发团队提升安全成熟度的两个主要方法